@tim-schilling I committed both of your suggestions. We can "squash merge" the PR at the end.

I don't have a strong opinion on the values; I'm actually a bit lost about them.

• add_member takes 11 seconds and member_verification takes 6 seconds on average. If these tasks take over a minute, it means they take 6x - 10x longer than usual, which could mean there is an issue, but I am not sure if we want to cut a task at a minute. Even though it's way over the average time, it's not long enough to have any negative effects on the CI setup.
• plan and apply are similar in their nature but
  • plan takes 6m5s in average. 10 minutes means ~65% longer than usual.
  • apply takes 2m49s in average. 10 minute means ~205% longer than usual.

and I'm not sure if any of these analyses are actually important 😬 I tend to set a limit with a logic that "if something takes a certain percentage longer than average, it should be timed out" but even if we use a global value like 15m, I'm not sure there would be any harm.

I may need to rebase/squash these so my name is associated with them. There's a bug in the plan action 🫠

Nope, that wasn't it. Sorry @ulgens if this gets a little noisy.

I think this won't run plan since it does not have access to the TF github token secret.

@cunla any ideas on why it doesn't?

Ah, because it's a fork, not the actual branch. Hmmm

Ah, because it's a fork, not the actual branch. Hmmm

I think we want to keep it that way, otherwise forks will have access to the github_token.
that's the diff between pull_request_target and pull_request trigger

Replaced by #364. Thank you @ulgens!